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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document is the result of a split of TS 23.048 Release 5 between the generic part and the bearers specific 
application. The generic part has been transferred to SCP. The present document is the bearers specific part. 
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Scope 



The present document specifies the structure of the Secured Packets in implementations using Short Message Service 
Point to Point (SMS-PP), Short Message Service Cell Broadcast (SMS-CB), and Unstructured Supplementary Service 
Data (USSD) based on ETSI TS 102 225 [9]. 

The structure of the Secured Packets shall comply with the one defined in ETSI TS 102 225 [9]. The present document 
only contains additional requirements or explicit limitations for SIM/USIM applications. 

It is applicable to the exchange of secured packets between an entity in a 3G or GSM PLMN and an entity in the 
(U)SIM. 

Secured Packets contain application messages to which certain mechanisms according to ETSI TS 102 224 [2] have 
been applied. Application messages are commands or data exchanged between an application resident in or behind the 
3G or GSM PLMN and on the (U)SIM. The Sending/Receiving Entity in the 3G or GSM PLMN and the UICC are 
responsible for applying the security mechanisms to the application messages and thus turning them into Secured 
Packets. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] ETSI TS 102 224 V7. 1 .0: "Smart Cards; Security mechanisms for UICC based AppHcations - 

Functional requirements". 

[3] 3GPP TS 23.040: "Technical reahzation of the Short Message Service (SMS)". 

[4] 3GPP TS 24.01 1 : "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio 

interface". 

[5] ETSI TS 101 220 "Smart Cards; ETSI numbering system for telecommunication application 

providers". 

[6] 3GPP TS 23.041: "Technical reahzation of Cell Broadcast Service (CBS)". 

[7] 3GPP TS 24.012: "Short Message Service Cell Broadcast (SMSCB) support on the mobile radio 

interface". 

[8] 3GPP TS 23.038: "Alphabets and language-specific information". 

[9] ETSI TS 102 225 V7.3.0: "Smart Cards; Secured packet structure for UICC based applications". 

[10] 3GPP TS 24.090: "Unstructured Supplementary Service Data (USSD) - Stage 3". 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in ETSI TS 102 225 [9] and the following 
apply: 

Message Identifier: two-octet field used to identify the source and type of the message 

Page Parameter: single octet field used to represent the CBS page number in the sequence and the total number of 
pages in the SMS-CB message 

Serial Number: two octet field which identifies a particular message 

It is linked to the Message Identifier and is altered every time the message is changed 

Short Message: information that may be conveyed by means of the SMS Service as defined in TS 23.040 [3]. 

USSD message: information that may be conveyed in the USSD-String field of a Facility message as defined in 
TS 24.090 [10]. 



3.2 



Abbreviations 



For the purpose of the present document, the abbreviations given in ETSI TS 102 225 [9] and the following apply: 

CBC Cipher Block Chaining 

CBS Cell Broadcast Service 

CCF Concatenation Control Field 

DCS Data Coding Scheme 

lEI Information Element Identifier 

lEIDL Information Element Identifier Data Length 

lED Information Element Data 

MID Message IDentifier 

MO-SMS Mobile Originated Short Message Service 

MT-SMS Mobile Terminated Short Message Service 

PFI Packet Format Information 

PLMN Public Land Mobile Network 

PP Page Parameter 

SIM Subscriber Identity Module 

SM Short Message 

SMS Short Message Service 

SMS-PP Short Message Service - Point to Point 

SMS-CB Short Message Service - Cell Broadcast 

SMS-SC Short Message Service - Service Centre 

SN Serial Number 

UM USSD message 

USIM Universal Subscriber Identity Module 

USSD Unstructured Supplementary Service Data 



4 Implementation for SIVIS-PP 

4.1 Structure of the UDH in a secured Short IVIessage Point to 
Point 

The coding of the SMS-DELIVER, SMS-SUBMIT, SMS-DELIVER-REPORT header shall indicate that the data is 
binary (8 bit data), and not 7 bit or 16 bit. In order to invoke the UDH functionality of relevant SMS element, the UDHI 
bit shall be set as defined in TS 23.040 [3]. 
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However, in the case of a Response Packet originating from the UICC, due to the inability of the UICC to indicate to a 
ME that the UDHI bit should be set, the Response Packet SMS will not have the UDHI bit set, and the Sending Entity 
shall treat the Response Packet as if the UDHI bit was set. 

The generalised structure of the UDH in the Short Message element is contained in the User Data part of the Short 
Message element and is described in TS 23.040 [3]. The Command Packet and the Response Packet are partially 
mapped into this UDH structure. 

Information Element Identifiers (lEI's) values range 70 - 7F' are reserved in TS 23.040 [3] for use in the present 
document and allocated as follows: 

70' and 7 1 ' are specified in the present document 

values 72 - 7D' are reserved for future use 

7E' and 7F' are for proprietary implementations. 

If a Response Packet (Response Header + Data) is too large to be contained in a single Short Message (including the 
Response Header), it shall be concatenated according to TS 23.040 [3]. 

If it is indicated in the SPI2 of a Command Packet to send back a PoR using SMS -DELI VER-REPORT and if the 
Response Packet is too large to be contained in a single SMS-DELIVER-REPORT - TP element, then: 

One single Response Packet shall be sent back to the SE using SMS-DELIVER-REPORT. This Response 
Packet: 

Shall not contain any additional response data. 

Shall contain the Response Status Code set to "Actual response data to be sent using SMS-SUBMIT". 

The security applied to this Response Packet shall be the one indicated in the SPI2 of the Command Packet. 

This shall be followed by a complete Response Packet, contained in one SMS-SUBMIT element or in a 
concatenated Short Message composed of several SMS-SUBMIT elements. 

4.2 Structure of the Command Packet contained in a Single 
Short IVIessage Point to Point 

CPI identifies the Command Packet and indicates that the first portion of the SM (8 bit data) contains the Command 
Packet Length (CPL), the Command Header Length (CHL) followed by the remainder of the Command Header: the 
Secured Data follows on immediately as the remainder of the SM element. 

The relationship between the Command Packet and its inclusion in the UDH structure of a single Short Message 
defined in TS 23.040 [3] is as following: 

- CPI is mapped to lEIa defined in TS 23.040 [3] and shall be set to 70'. 

- lEDa defined in TS 23.040 [3] shall be a null field and its length lEIDLa shall be set to '00'. 

The following Table 1 indicates the Command Packet contained in a single SMS-PP. It is a particular implementation 
for single SMS-PP of the generic Command Packet structure described in ETSI TS 102 225 [9]. 
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Table 1 : Structure of the Command Packet contained in the SIUI (8 bit data) 



Command Packet 
Elements 


Length 


Description 


Command Packet 
Length 


2 octets (see NOTE) 


Length of the Command Packet (CPL), coded over 2 
octets, and shall not be coded as the length of BER-TLV 
data objects described in ETSI TS 101 220 [5]. 


Command Header 
Identifier 


Null field 


(CHI) Null field. 


Command Header 
Lengtii 


1 octet 


Length of the Command Header (CHL), coded over one 
octet, and shall not be coded as the length of BER-TLV 
data objects described in ETSI TS 101 220 [5]. 


SRI to RC/CC/DS in 
the Command 
Header 


Variable 


The remainder of the Command Header as described in 
ETSI TS 102 225 [9]. 


Secured Data 


Variable 


Application IVIessage, including possible padding octets as 
described in ETSI TS 102 225 [9]. 



NOTE: Whilst not absolutely necessary in this particular instance, this field is necessary for the case where 
concatenated Short Message is employed (see subclause 4.3). 

It is recognised that most checksum algorithms require input data in modulo 8 length. In order to achieve a modulo 8 
length of the data before the RC/CC/DS field in the Command Header the Length of the Command Packet and the 
Length of the Command Header shall be included in the calculation of RC/CC/DS if used. These fields shall not be 
ciphered. 

The SPI shall be coded as specified in ETSI TS 102 225 [9]. The b6 of the second octet is used for SMS only and shall 
be coded as followed: 

Second Octet: 



b8 b7 b6 b5 b4 b3 b2 b1 



Coded as defined in ETSI TS 102 225 [9] 

Coded as defined in ETSI TS 102 225 [9] 

Coded as defined in ETSI TS 102 225 [9] 

For SIVIS only 

0: PoR response shall be sent using 

SIVIS-DELIVER-REPORT 
1 : PoR response shall be sent using SIVIS-SUBMIT 

Coded as defined in ETSI TS 102 225 [9] 



4.3 A Command Packet contained in Concatenated Short 
IVIessages Point to Point 

If a Command Packet is longer than 140 octets (including the Command Header), it shall be concatenated according to 
TS 23.040 [3]. 

The relationship between the Command Packet and its inclusion in the structure of a concatenated Short Message 
defined in TS 23.040 [3] is as following: 

The entire Command Packet including the Command Header shall be separated into its component concatenated 
parts. The structure of the Command Packet contained in a concatenated SMS-PP is as described in Table 1 of 
this specification. 

The first Short Message shall contain the Concatenation Control Header as defined in TS 23.040 [3] identified 
by lEIx and the Command Packet Identifier (CPI) in the User Data Header. The relationship between the 
Command Packet and its inclusion in the structure of the first concatenated Short Message is as described in 
clause 4.2 for a single Short Message. 
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NOTE: The ordering of the various elements of the UDH defined in TS 23.040 [3] is not important. 

In each subsequent Short Message in the concatenated series, the Concatenation Control Header shall be present. 
The Concatenation Control Header shall be set as defined in TS 23.040[3]. The CPI, CPL and Command Header 
shall not be present. 

Example of concatenation, 8-bit reference number: 

if in the first Short Message the Concatenation Control Header isidentified by lEIa, the CPI is 
mapped to lEIb and no other lEI is present, then the UDHL fieldcontains the length of the total 
User Data Header i.e the Concatenation Control Header, the CPI and lEIDLb (UDHL shall be set 
to '07' with lEIa set to '00'). In subsequent Short Message's in the concatenated series, the UDHL 
contains the length of the Concatenation Control Header only, as there is no subsequent Command 
Packet Information Element CPI and lEIDLb). 

If the data is ciphered, then it is ciphered as described above, before being broken down into individual concatenated 
elements. The Concatenation Control Header of the UDH in each SM shall not be ciphered. 

In order to achieve a modulo 8 length of the data before the RC/CC/DS field in the Command Header, the Length of the 
Command Packet and the Length of the Command Header shall be included in the calculation of RC/CC/DS if used. 
These fields shall not be ciphered. 

The SPI shall be coded as specified in TS 102 225 [9]. The b6 of the second octet is used only for SMS and shall be 
coded as described for a single short message. 

An example illustrating the relationship between a Command Packet split over a sequence of three Short Messages is 
shown below. 



The Command Header includes here CPL, CHL, SPI to RC/CC/DS 

Figure 2: Example of command split using concatenated point to point SIVIS 

4.4 Structure of the Response Packet 

The Response Packet is as follows. This message is generated by the Receiving Entity and possibly includes some data 
supplied by the Receiving Application, and returned to the Sending Entity/Sending Application. In the case where the 
Receiving Entity is the UICC, depending on bit 6 of the second octet of the SPI, this Response Packet is generated on 
the UICC, either: 

- retrieved by the ME from the UICC, and included in the User-Data part of the SMS-DELIVER-REPORT 
returned to the network; or 

fetched by the ME from the UICC after the Send Short Message proactive command. 

The structure of an SMS-DELIVER/SUBMIT User Data object is defined in TS 23.040 [3]. 

RPI identifies the Response Packet and indicates that the first portion of the SM (8 bit data) contains the Response 
Packet Length (RPL), the Response Header Length (RHL) followed by the remainder of the Response Header: the 
Secured Data follows on immediately as the remainder of the SM element. 
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The relationship between the Response Packet and its inclusion in the UDH structure of a single Short Message defined 
in TS 23.040 [3] is as following: 

- RPI is mapped to lEIa defined in TS 23.040 [3] and shall be set to 71'. 

- lEDa defined in TS 23.040 [3] shall be a null field and its length lEIDLa shall be set to '00'. 

The following Table 3 indicates the Response Packet contained in a single SMS -PP. It is a particular implementation for 
single SMS-PP of the generic Response Packet structure described in ETSI TS 102 225 [9]. 

Table 3: Structure of the Response Packet contained in the SM (8 bit data) 



Generalised Response 
Packet Elements 
(Refer to table 3) 


Length 


Description 


Response Packet 
Length 


2 octets 


Length of the Response Packet (RPL), coded over 2 octets, and 
shall not be coded as the length of BER-TLV data objects described 
in ETSI TS 101 220 [5]. (see note) 


Response Header 
Identifier 




(RHI) Null field. 


Response Header 
Length 


1 octet 


Length of the Response Header (RHL), coded over one octet, and 
shall not be coded as the length of BER-TLV data objects described 
in ETSI TS 101 220 [5]. 


TAR to RC/CC/DS 
elements in the 
Response Header 


Variable 


The remainder of the Response Header as described in 

ETSI TS 102 225 [9]. 

Response Status Codes are defined in clause 7. 


Secured Data 


Variable 


Additional Response Data (optional), including padding octets as 
described in ETSI TS 102 225 [9]. 



NOTE: This field is not absolutely necessary but is placed here to maintain compatibility with the structure of the 
Command Packet when included in a SMS-SUBMIT or SMS-DELIVER. 

In order to achieve a modulo 8 length of the data before the RC/CC/DS field in the Response Header, the Length of the 
Response Packet, the Length of the Response Header and the three preceding octets (UDHL, lEIa and lEIDLa defined 
in TS 23.040 [3]) shall be included in the calculation of RC/CC/DS if used. These fields shall not be ciphered. 

4.5 A Response Packet contained in Concatenated Short 
IVIessages Point to Point 

The relationship between the Response Packet and its inclusion in the structure of a concatenated Short Message 
defined in TS 23.040 [3] is as following:The entire Response Packet including the Response Header shall be 
separated into its component concatenated parts. The structure of the Response Packet contained in a 
concatenated SMS-PP is as described in Table 5 of this specification. 

The first Short Message shall contain the Concatenation Control Header as defined in TS 23.040 [3] identified 
by lEIxand the Response Packet Identifier (RPI) in the User Data Header. The relationship between the 
Response Packet and its inclusion in the structure of the first concatenated Short Message is as described in 
clause 4.4 for a single Short Message. 

NOTE: The ordering of the various elements of the UDH defined in TS 23.040 [3] is not important. 

In each subsequent Short Message in the concatenated series, the Concatenation Control Header shall be present. 
The concatenation Control Header shall be set as defined in TS 23.040 [3]. The RPI, RPL and Response Header 
shall not be present. 

Example of concatenation, 8-bit reference number: 

if in the first Short Message the Concatenation Control Header is identified by lEIa, the RPI is 
mapped to lEIb and no other lEI is present, then the UDHL field contains the length of the total 
User Data Header i.e the Concatenation Control Header, the RPI and lEIDLb (UDHL shall be set 
to '07' with lEIa set to '00'). In subsequent Short Message's in the concatenated series, the UDHL 
contains the length of the Concatenation Control Header only, as there is no subsequent Response 
Packet Information Element (RPI and lEIDLb). 
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Table 5: Structure of the Response Packet contained in the SIUI (8 bits data) 



SMS-REPORT 
specific Elements 
(Refer to table 3) 


Length 


Comments 


RPL 


2 octets 


Length of the Response Packet (RPL), coded over 2 
octets, and shall not be coded as the length of BER-TLV 
data objects described in ETSI TS 101 220 [5]. 


RHI 




(RHI) Null field. 


RHL 


1 octet 


Length of the Response Header (RHL), coded over one 
octet, and shall not be coded as the length of BER-TLV 
data objects described in ETSI TS 101 220 [5]. 


TAR to RC/CC/DS 
elements in the 
Response Header 


Variable 


The remainder of the Response Header as described in 
ETSI TS 102 225 [9]. 


Secured Data 


Variable 


Additional Response Data (optional), including padding 
octets as described in ETSI TS 102 225 [9]. 



If the data is ciphered, then it is ciphered as specified in ETSI TS 102 225 [9], before being broken down into individual 
concatenated elements. The concatenation Control Header of the UDH in each SM shall not be ciphered. 

In order to achieve a modulo 8 length of the data before the RC/CC/DS field in the Response Header, the RPL, the RHL 
and three octets set to '02' '71' '00', which precede the RPL, shall be included in the calculation of RC/CC/DS if used. 
These fields shall not be ciphered. 



5 Implementation for SMS-CB 

5.1 Structure of the CBS page in the SIVIS-CB IVIessage 

The CBS page sent to the MS by the BTS is a fixed block of 88 octets as coded in TS 24.012 [7]. The 88 octets of CBS 
information consist of a 6-octet header and 82 user octets. 

The 6-octet header is used to indicate the message content as defined in TS 23.041 [6]. This information is required to 
be transmitted unsecured in order for the ME to handle the message in the correct manner (e.g. interpretation of the 
DCS). 

The content of the message shall be secured as defined in this subclause. 

A range of values has been reserved in TS 23.041 [6] to indicate SMS-CB Data Download messages that are secured 
and unsecured. A subset of these values is used to indicate the Command Packet for CBS messages. 

5.2 A Command Packet contained in a SIVIS-CB message 

The relationship between the Command Packet and its inclusion in the SMS-CB message structure defined in 
TS 23.041 [6] is the following: 

CPI coded on 2 octets is mapped to MID defined in TS 23.041 [6] and the range is from (hexadecimal) '1080' to 
'109F'. This range is reserved in TS 23.041 [6]. 

NOTE: Generally, the CPI is coded on 1 octet, as specified in table 1 of ETSI TS 102 225 [9]. However, the CPI 
for the SMS-CB message is coded on 2 octets as the values reserved in TS 23.041 [6] to identify the 
Command Packet are MID values which are coded on 2 octets. 

- SN, DCS, PP shall be coded as defined in TS 23.041 [6] for GSM Cell Broadcast. 

The structure of the Command Packet contained in the Content of Message of the first CBS page is as described in 
Table 1 of this specification. 

It is recognised that most checksum algorithms require input data in modulo 8 length. In order to achieve a modulo 8 
length of the data before the RC/CC/DS field in the Command Header the Length of the Command Packet and the 
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Length of the Command Header shall be included in the calculation of RC/CC/DS if used. These fields shall not be 
ciphered. 

Securing of the complete CBS message is achieved outside the 3G and GSM specifications by the Sending Entity. The 
Secured CBS message is formatted in accordance with the 3G and GSM specifications and transmitted to the MS as 
CBS pages. The CBS pages are received by the ME and sent directly to the UICC, by analysing the MID value. The 
UICC shall then reassemble, decrypt and process the message. 

An example illustrating the relationship between a Command Packet split over a sequence of three SMS-CB pages is 
shown below. 



CH I Secured Data I Padding 



/ \ 



Header 


CH 





Header 





Header 





First CBS page in the sequence 



Second CBS page 



Third and final CBS page 



In the above figure, Header = 6 Octet header as defined in TS 23.041 [6] (i.e. SN, MID, DCS and PP) and 
CH = Command Header includes here the CPL, CHL, SPI to RC/CC/DS. 

Figure 3: Example of command split using concatenated CB SMS 

5.3 Structure of the Response Packet for a SMS-CB Message 

As there is no response mechanism defined for SMS-CB, there is no defined structure for the (Secured) Response 
Packet. However, if a (Secured) Response Packet is sent via another bearer the structure shall be defined by the 
Receiving Application. 



6 Implementation for USSD 

The USSD application mode enables the transparent transport of data between an application residing in the network 
and a UICC based application. In such a case, to secure the payload of USSD operations, security mechanisms defined 
in TS 102 225 [9] shall be applied to the USSD messages. Generic secured Command Packet and secured Response 
Packet as defined in TS 102 225 [9] are contained, as defined hereafter, in the UM part of the USSD String. The USSD 
String shall be formatted according to annex X, where the PFI byte indicates that Application Data are formatted 
according to the present document. 

The Data Coding Scheme of the USSD String (as defined in TS 23.038 [8]) shall be set to 0x96 (DCS = '10010110') to 
indicate that data is binary (8 bit data), and formatted according to annex X. In USSD Application mode, which uses an 
8-bit character set, the maximum length of the USSD String field is 160 bytes. 

Command and Response packets exceeding 159 bytes shall be segmented as described in sections 6.2 and 6.4. 

6.1 Structure of the Command Packet contained in a Single 
USSD Message 

The UM field of an USSD String contains the Command Packet. 

The Command Packet shall be coded as the generic Command Packet described in TS 102 225 [9]. 

In the Command Packet, the Command Packet Identifier (CPI) value is '03' and the Command Header Identifier (CHI) 
is a Null field. 

CPI, CPL and CHL shall be included in the calculation of the RC/CC/DS. 
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The SPI shall be coded as specified in TS 102 225 [9]. 

6.2 Structure of the Command Packet contained in 
concatenated USSD IVIessages 

If the Command Packet, which is structured as described in section 6.1, is longer than 159 bytes (including the 
Command Header) then it shall be handled as follows. 

The entire Command Packet including the Command Header shall be separated into its component concatenated 
parts. 

The Command Packet is handled as a Concatenated USSD Message as described in annex X of the present 
document. 

The Command Packet Header will only be present in the first segment of a concatenated message. 

If the data is ciphered, then it is ciphered as described above, before being broken down into individual concatenated 
elements. 

CPI, CPL and CHL shall be included in the calculation of the RC/CC/DS. 

The SPI shall be coded as specified in TS 102 225 [9]. 

An example illustrating a Command Packet split over a sequence of three messages is shown below. 



CH 



Secured Data 




First message in sequence 




PFI 


CCFl 


CH 





Second message 




PFI 


CCF2 





PFI 


CCF3 





Third and last message 



Where CCFn = Concatenation Control Field (1,2,3) 
PFI = Packet Format Information (see Annex) 
CH = Command Header 



Figure 4: Example of command split using concatenated USSD messages 

6.3 Structure of the Response Packet 

The Response Packet is generated by the Receiving Entity and possibly includes some data supplied by the Receiving 
Application, and returned to the Sending Entity/Sending Application. In the case where the Receiving Entity is the 
UICC, this Response Packet is generated on the UICC, retrieved by the ME from the UICC, and included in the Return 
Result Component of a Facility message (see TS 24.090 [10]) returned to the network. 

The USSD operations are defined in TS 24.090 [xx]. 

The UM field of an USSD String contains the Response Packet. 

The Response Packet shall be coded as the generic Response Packet described in TS 102 225 [9]. 

In the Response Packet, the Response Packet Identifier (RPI) value is '04' and the Response Header Identifier (RHI) is a 
Null field. 

RPI, RPL and RHL shall be included in the calculation of the RC/CC/DS. 
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Coding of Response Status Codes is defined in clause 7. 

6.4 Structure of the Response Packet contained in 
concatenated USSD IVIessages 

If the Response Packet, which is structured as described in section 6.3, is longer than 159 bytes (including the Response 
Header) then it shall be handled as follows. 

The entire Response Packet including the Response Header shall be separated into its component concatenated 
parts. 

The Response Packet is handled as a Concatenated USSD Message as described in annex X of the present 
document. 

The Response Packet Header will only be present in the first segment of a concatenated message. 

If the data is ciphered, then it is ciphered as described above, before being broken down into individual concatenated 
elements. 

RPI, RPL and RHL shall be included in the calculation of the RC/CC/DS. 

An example illustrating a Response Packet split over a sequence of three messages is shown below. 



RH 



Secured Data (Optional) 





PFI 


CCFl 


RH 






PFI 


CCF2 





PFI 


CCF3 





First message in sequence 



Second message 



Third and last message 



Where CCFn = Concatenation Control Field (1,2,3) 
PFI = Packet Format Information (see Annex) 
RH = Response Header 



Figure 5: Example of Response split using concatenated USSD messages 

If it is indicated in the SPI2 of a Command Packet to send back a PoR and if the Response Packet is too large to be 
contained in a single USSD String, then: 

One single Response Packet shall be sent back to the SE using the Return Result Component contained in the 
subsequent Facility message. This Response Packet: 

Shall not contain any additional response data 

Shall contain the Response Status Code set to 'OC (Actual response data to be sent using a 
ProcessUnstructuredSS-Request invoke component (i.e. using SEND USSD proactive command) '). 

The security applied to this Response Packet shall be the one indicated in the SPI2 of the Command Packet. 

This shall be followed by a complete Response Packet, contained in a concatenated USSD Message as defined 
above 
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7 Specific Response Status Codes 


Status Code 
(hexadecimal) 


Meaning 


'00' to 'OA' 


See TS 102 225 [9] 


'OB' 


Actual response data to be sent using SMS-SUBMIT. See section 4.4. 


'OC 


Actual response data to be sent using a ProcessUnstructuredSS-Request invoke 
component (i.e. using Send USSD proactive command). See section 6.3 


'OD' - 'FF' 


See TS 102 225 [9] 



Specific Response Status Codes 
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Annex A (normative): 
USSD String format 



For the purpose of UlCC-based application, the USSD String shall be coded as follows: 



Header 



PFI 


CCF 


UM (USSD Message) 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


















1 
X 
























X 





1 
























1 


















1 





1 



Figure 6: USSD String format 

The header of an USSD Message may contain two fields: 

A mandatory PFI field, which is coded on 1 byte. The PFI contains information on the format of the USSD 
String. 

An optional CCF field, which is coded on 3 bytes. The CCF field presence is indicated by the PFI. 

The PFI is coded as follows. 



Proprietary Application Data format 

Application Data formatted according to the present document. 

If b2 b1 = '01' (Application Data formatted according to the present 
document), then b3 shall be coded as follows: 

No CCF field 
CCF field present 

Reserved for future use 



The usage of CCF field allows USSD Messages to be concatenated to form a longer message. The CCF field contains 
information set by the application so that the receiving entity is able to re-assemble the received UMs in the correct 
order. Additionally, the CCF contains a reference number, which allows the receiving entity to discriminate between 
messages. The CCF octets shall be coded as follows. 

Octet 1: Concatenated USSD Message reference number. 

This octet shall contain a modulo-256 counter indicating the reference number for a particular USSD 
Message, Concatenated or not. This reference number shall remain constant for every USSD Message 
that makes up a particular Concatenated USSD Message. 

Octet 2: Total number of USSD Messages in the Concatenated USSD Message. 

This octet shall contain a value in the range 1 to 255 indicating the total number of USSD Messages 
constituting the Concatenated USSD Message. The value shall start at 1 and remain constant for every 
USSD Message that makes up the Concatenated USSD message. If the value is zero then the receiving 
entity shall ignore the whole USSD Message. 

Octet 3: Sequence number of the current USSD Message. 

This octet shall contain a value in the range 1 to 255 indicating the sequence number of a particular USSD 
Message within the Concatenated USSD Message. The value shall start at 1 and increment by one for 
every USSD Message sent within the Concatenated USSD Message. If the value is zero or the value is 
greater than the value in octet 2 then the receiving entity shall ignore the whole USSD Message. 

The UM field contains the actual application data (e.g. secure Command/Response Packets coded according to the 
present document). 
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In each USSD String in a concatenated series, the PFI and CCF fields shall be present. 
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Annex B (informative): 
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